我們用 SMART——Specific（具體）、Measurable（可衡量）、Achievable（可達成）、Relevant（具關聯）、Time-bound（有時限）——把每個故事拆成五天，作為每次動手造輪子前的五個檢查問題。

本篇是故事四「從 ONVIF 攝影機截圖太難了，我們來搞 V4L2」的 Time-bound 篇：何時要完成？何時必須停止研究、重構或自研？

本篇定位：建立協定探勘與升級處理層級的時間界線。

當時發生了什麼

復盤會開到一半，有人問了一句很普通的話：「跨進攝影機裡面這個決定，當初是誰拍板的？」

會議室安靜了幾秒。我們翻了會議紀錄，翻了工單，連討論串都往回捲了一段——找不到那一筆。沒有結論、沒有評估、沒有任何人核准；只有兩天沒進展的挫折，加上一次成功登入的興奮，方向就自己轉了。一個會改變整個專案維護結構的決定，發生得像順手開了另一個終端機視窗那樣自然。

如果不是後來有人把驗收表和責任清單攤開，這個「順手」大概會一路長成交付物。

真正的問題在哪裡

沒有時間界線的探勘，最後都由情緒接管。挫折兩天，成了放棄上層協定的理由；一次登入成功，成了底層可行的證明——但兩者都不是證據。

「試了兩天沒成功」證明的只是還沒學會，這一點在補那張階梯時已經講清楚了。真正沒被回答的是後半段：這個「還沒學會」可以持續多久？到什麼時候、由誰，才有資格把它改判成「確實不支援」？當初沒有人問，於是它由當下最不耐煩的那個人回答了。

反過來說，探勘也不能無限期。如果那時有人規定「標準介面研究到通為止」，我們可能在規格書裡再泡兩週。時限的意義是雙向的：它逼你在期限內拿出證據，也保護你不被「再研究一下」無限吸走。少了它，放棄太快與堅持太久這兩種病，會輪流發作。

而最該有門檻的那一步——跨進設備內部——恰恰是當時唯一免審查的一步。它影響保固、升級、資安與後續每一個接手的人，卻只需要一組預設密碼。

可以怎麼做

先給標準介面一個短週期探勘：以天計，不以週計。這個週期可以再切成兩個節點。前半段是能力盤點——翻文件、看設備的網頁介面，確認它宣告支援哪些服務、通過哪一套一致性規範，產出是一張「它說它會做什麼」的清單。後半段是最小可行的 PoC：只做一條路，連上、認證、取得媒體設定檔、要到截圖，不做重試、不做封裝、不做錯誤處理，唯一目的是讓標準路徑當場說「通」或「不通」。時間盒內只做這件事，時間到就收，不熬夜加碼。

時間盒到期時，要交得出三份東西：設備宣告的能力清單、PoC 停在哪一步、停住當下的錯誤與回應原文。三份齊全，才有資格說「不支援」；交不出第三份，結論就只能是「還沒弄對」——而還沒弄對的處理方式是回去找工具、查文件，不是換戰場。這一條要寫進時間盒的定義裡，別留給到期那天各自解讀。

要往下一級——從標準介面到串流擷取、到廠商 API、再到設備端修改——每一級都是一次明確的決定：有紀錄、有人核准，不是誰先做出來就算數。核准的層級也該隨深度提高：停留在標準與串流這兩級，技術負責人點頭即可，因為後果還關在我們自己的系統裡；要動到廠商 SDK，得讓採購與維護的人知道我們正在綁定一家供應商；要進設備內部，影響的是客戶資產的保固與資安，這已經不是工程團隊單獨能決定的事，必須讓專案負責人與客戶端一起在場。

到了設備端修改這一級，核准前還必須先寫下成本與退場：程式怎麼部署、誰維護、原廠韌體升級時怎麼辦、行不通時怎麼退回上一級。寫不出退場方式的方案，不是大膽，是單程票。

這套流程聽起來像官僚，其實只是還原重量：決策成本應該和後果成正比。當跨越邊界變得免費，團隊就會在挫折的低點順手跨過去——然後在維護的高點付清全款。

今天學到的事

這個故事的手擀破輪子模式，是第四種：因為上層陌生，就逃到更底層重新開始。它和前三種一樣，起點都不是惡意——底層是我們熟悉的世界，往熟悉的地方走，永遠感覺比較快。但整合問題不會因為換到底層就消失，只會多出一整層別人本來替你扛著的責任。原本只需要向攝影機要一張照片，最後卻因為不想理解門鈴怎麼按，決定翻牆進屋裡拆監視器。

故事四裡，我們是那個看不懂別人介面的人。但菜鳥的修煉是全方位的——下一個故事，角色對調：這次是我們寫的 API、我們出的 OpenAPI 文件，而擔心看不懂的人，變成了客戶。當「別人可能看不懂我的介面」時，我們的第一反應會是什麼？明天開始故事五。